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Abstract 


The  Carnegie  Mellon®  Software  Engineering  Institute  held  the  Seventh  Department  of  De¬ 
fense  (DoD)  Product  Line  Practice  Workshop  in  September  2004.  The  workshop  was  a 
hands-on  meeting  to  share  DoD  product  line  practices,  experiences,  and  issues  and  to  discuss 
ways  in  which  specific  product  line  practices  are  accomplished  within  the  DoD.  Participants 
reported  encouraging  progress  on  DoD  software  product  lines.  This  report  synthesizes  the 
workshop  presentations  and  discussions. 


iii 
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1  Introduction 


1.1  Product  Line  Practice 

An  increasing  number  of  organizations  are  realizing  that  they  can  no  longer  afford  to  develop 
multiple  software  products  one  product  at  a  time:  they  are  pressured  to  introduce  new  prod¬ 
ucts  and  add  functionality  to  existing  ones  at  a  rapid  pace.  They  have  explicit  needs  to 
achieve  large-scale  productivity  gains,  improve  time  to  market,  maintain  a  market  presence, 
compensate  for  an  inability  to  hire,  leverage  existing  resources,  and  achieve  mass  customiza¬ 
tion.  Many  organizations  are  finding  that  the  practice  of  building  sets  of  related  systems  to¬ 
gether  can  yield  remarkable  quantitative  improvements  in  productivity,  time  to  market,  prod¬ 
uct  quality,  and  customer  satisfaction.  Those  organizations  are  adopting  a  product  line 
approach  for  their  software  systems. 

A  software  product  line  is  a  set  of  software-intensive  systems  sharing  a  common,  managed 
set  of  features  that  satisfy  the  specific  needs  of  a  particular  market  segment  or  mission  and 
that  are  developed  from  a  common  set  of  core  assets  in  a  prescribed  way  [Clements  02]. 

In  January  1997,  the  Carnegie  Mellon®  Software  Engineering  Institute  (SEI)  launched  the 
Product  Line  Practice  Initiative  to  help  facilitate  and  accelerate  the  transition  to  sound  soft¬ 
ware  engineering  practices  using  a  product  line  approach.  The  goal  of  this  initiative  is  to  pro¬ 
vide  organizations  with  an  integrated  business  and  technical  approach  to  systematic  reuse,  so 
they  can  produce  and  maintain  similar  systems  of  predictable  quality  more  efficiently  and  at  a 
lower  cost. 

A  key  strategy  for  achieving  this  goal  has  been  the  creation  of  a  conceptual  framework  for 
product  line  practice.  The  SEI  Framework  for  Software  Product  Line  Practice SM  (henceforth 
referred  to  as  “the  framework”)  describes  the  foundational  product  line  concepts  and  identi¬ 
fies  the  essential  activities  and  practices  that  an  organization  must  master  before  it  can  expect 
to  field  a  product  line  of  software  or  software-intensive  systems  successfully.  The  framework 
organizes  product  line  practices  into  practice  areas  that  are  categorized  as  software  engineer¬ 
ing,  technical  management,  or  organizational  management.  (These  categories  represent  disci¬ 
plines  rather  than  job  titles.)  The  framework  is  a  living  document  that  is  evolving  as  experi¬ 
ence  with  product  line  practice  grows.  Version  4.0  is  described  in  the  book  Software  Product 
Lines:  Practices  and  Patterns  [Clements  02],  and  the  latest  version  is  available  on  the  SEI 
Web  site  [Clements  04], 


®  Carnegie  Mellon  is  registered  in  the  U.S.  Trademark  and  Patent  Office. 

SM  Framework  for  Software  Product  Line  Practice  is  a  service  mark  of  Carnegie  Mellon  University. 
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The  framework’s  contents  are  based  on  information-gathering  workshops,1  extensive  work 
with  collaboration  partners,  surveys  and  investigations,  and  continued  research.  The  SEI  has 
also  incorporated  practices  reported  at  its  international  Software  Product  Line  Conferences 
[Donohoe  00,  Chastek  02,  Nord  04]  and  collected  from  the  community. 

In  March  1998,  the  SEI  hosted  its  first  Department  of  Defense  (DoD)  product  line  practice 
workshop.  Product  Lines:  Bridging  the  Gap — Commercial  Success  to  DoD  Practice.  Product 
line  practices,  DoD  barriers  and  mitigation  strategies,  and  similarities  and  differences  be¬ 
tween  DoD  product  line  practice  and  commercial  product  line  practices  were  discussed  and 
documented  [Bergey  98].  Subsequent  workshops  were  held  in  successive  years  [Bergey  99, 
Bergey  00a,  Bergey  01,  Bergey  03,  Bergey  04a].  At  all  six  DoD  workshops,  the  SEI  was  en¬ 
couraged  to  continue  to  hold  other  DoD  workshops  and  to  continue  to  share  best  commercial 
and  DoD  practices  through  these  forums. 

One  of  the  key  outcomes  of  these  workshops  was  the  identification  of  product  line  practices 
that  were  particularly  important  to  DoD  acquisition  organizations.  This  information  sup¬ 
ported  development  of  a  companion  to  the  framework,  titled  Software  Product  Line  Acquisi¬ 
tion:  A  Companion  to  A  Framework  for  Software  Product  Line  Practice  [Bergey  04b]  (hence¬ 
forth  referred  to  as  “the  companion”).  The  companion,  like  the  framework,  is  a  living 
document  with  the  latest  version  available  on  the  SEI  Web  site  at  http://www.sei.cmu.edu 
/productlines/companion.html. 

1 .2  About  This  Workshop 

The  goals  of  the  Seventh  DoD  Product  Line  Practice  Workshop  in  September  2004  were  to 

•  share  DoD  product  line  practices,  experience,  and  issues  regarding  both  development  and 
acquisition 

•  discuss  ways  to  motivate  product  line  efforts  in  support  of  DoD  systems 

•  explore  ways  to  initiate  software  product  line  adoption  in  the  DoD  community 

All  participants  in  this  workshop  were  from  the  DoD  acquisition  and  contractor  community. 
They  were  invited  based  on  our  knowledge  of  their  experience  with  and  commitment  to  soft¬ 
ware  product  lines  as  either  DoD  system  acquirers  or  DoD  system  contractors.  Together,  we 
discussed  the  issues  that  form  the  backbone  of  this  report. 

The  format  of  this  workshop  differed  somewhat  from  our  past  workshops.  Participants  were 
invited  to  make  brief  presentations  about  their  organizations’  activities  and  interests  in  soft¬ 
ware  product  lines.  The  intent  was  to  limit  discussion  during  these  presentations  and  to  save 
detailed  discussion  for  later  breakout  sessions.  However,  given  the  richness  of  the  presenta¬ 
tions  and  associated  discussions,  the  group  asked  to  extend  the  presentation  activities  in  lieu 
of  the  breakout  sessions.  Because  of  the  small  group  size,  the  facilitators  could  accommodate 


1  The  results  of  some  of  these  workshops  are  documented  in  SEI  reports  [Bass  97,  Bass  98,  Bass  99, 
Bass  00,  Clements  01]. 
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this  request.  After  the  workshop,  the  group  agreed  that  this  more  inclusive  participation 
worked  well. 

The  workshop  participants  included 

•  Thomas  Baker,  Austin  Information  Systems 

•  James  Baxter,  U.S.  Army  Program  Executive  Office  (PEO)  Aviation 

•  John  Bergey,  Product  Line  Systems  Program,  SEI 

•  Peter  Blankenship,  Northrop  Grumman 

•  Stephanie  Bums,  Rockwell  Collins 

•  Matthew  Cerroni,  U.S.  government  systems  engineer 

•  Sholom  Cohen,  Product  Line  Systems  Program,  SEI 

•  David  DeKing,  United  Defense  LP 

•  Patrick  Donohoe,  Product  Line  Systems  Program,  SEI 

•  Dave  Drum,  Argon  Engineering  Associates 

•  Edward  Dunn,  U.S.  Navy  Naval  Undersea  Warfare  Center  (NUWC) 

•  Scott  Harris,  Argon  Engineering  Associates 

•  William  Johnson,  PEO  Deputy  for  Open  Architecture,  U.S.  Navy 

•  Lawrence  Jones,  Product  Line  Systems  Program,  SEI 

•  Linda  Northrop,  Director,  Product  Line  Systems  Program,  SEI 

•  Frank  Polster,  U.S.  Army  Training  Support  Center  (ATSC) 

•  Dean  Runzel,  U.S.  Army  PEO  for  Simulation,  Training,  &  Instrumentation  (STRI) 

•  Stuart  Ware,  Argon  Engineering  Associates 

1 .3  About  This  Report 

This  document  summarizes  the  presentations  and  discussions  from  the  workshop.  This  report 
is  written  primarily  for  those  in  the  DoD  who  are  already  familiar  with  product  line  concepts, 
especially  those  working  on  or  initiating  product  line  practices  in  their  own  organizations. 
Acquisition  managers  and  technical  software  managers  should  also  benefit  from  this  report. 
Those  who  desire  further  background  information  are  referred  to  the  following  publications: 

•  Basic  Concepts  of  Product  Line  Practice  for  the  DoD  [Bergey  00b] 

•  A  Framework  for  Software  Product  Line  Practice ,  Version  4.2  [Clements  04] 

•  Software  Product  Line  Acquisition:  A  Companion  to  A  Framework  for  Software  Product 
Line  Practice,  Version  3.0  [Bergey  04b] 

•  Software  Product  Lines:  Practices  and  Patterns  [Clements  02] 

The  next  section  of  this  report  contains  a  digest  of  the  presentations.  The  report  concludes 
with  a  brief  summary. 
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2  DoD  Software  Product  Line  Experiences 
A  Digest  of  Participant  Presentations 


2.1  Introduction 

Peter  Blankenship  of  Northrop  Grumman  gave  a  keynote  presentation.  In  addition,  all  par¬ 
ticipants  were  invited  to  give  a  short  presentation  about  their  organizations’  product  line  in¬ 
terests  and  experiences.  A  summary  of  these  presentations  follows. 

2.2  Force  XXI  Battle  Command  Brigade  and  Below 
(FBCB2) — Peter  Blankenship,  Northrop 
Grumman 

Force  XXI  Battle  Command  Brigade  and  Below  (FBCB2)  is  an  Army  tactical  command  and 
control  system  designed  and  built  for  on-the-move  operations.  The  primary  development  con¬ 
tractor  is  Northrop  Grumman  Mission  Systems  (NG)  with  acquisition  services  provided  by 
the  FBCB2  Program  Office  (PO),  Fort  Monmouth,  NJ. 

A  deployed  FBCB2  system  consists  of  a  network  of  operational  platforms  (e.g.,  tanks,  heli¬ 
copters,  operations  centers),  each  with  its  own  FBCB2  configuration  of  hardware  and  soft¬ 
ware.  The  Tactical  Internet  (TI)  provides  the  network  communications  infrastructure.  The  TI 
utilizes  line-of-sight  tactical  radios  augmented  with  beyond-line-of-sight  satellite  communi¬ 
cations.2  The  hardware  for  a  platform  configuration  includes  computers,  displays,  Global  Po¬ 
sitioning  System  (GPS)  receivers,  installation  kits,  and  equipment  interfaces.  FBCB2  exists 
on  diverse  platforms,  including  the  M1A1  Abrams,  M2A3  Bradley,  M109A6  Paladin,  a  vari¬ 
ety  of  High-Mobility  Multipurpose  Wheeled  Vehicle  (HMMWV)  configurations,  and  Army 
Aviation  UH-60,  AH-64,  OH-58,  and  EH-60  helicopters. 

FBCB2  fulfills  two  primary  missions  for  tactical  maneuver  troops: 

1.  situational  awareness  (SA),  including 

-  Blue  Force  Tracking  (BFT)  (e.g.,  friendly  position  reports) 


2  The  tactical  radios  include  Enhanced  Position  Location  Reporting  System  (EPLRS)  and  Single 
Channel  Ground  and  Airborne  Radio  System  (SINCGARS).  Satellite  communication  links  include 
both  Military  Satellite  Communications  (MILSATCOM)  assets  and  commercial  L-Band  links.  The 
Tactical  Internet  Management  System  (TIMS)  provides  network  monitoring  and  management  ser¬ 
vices. 
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-  enemy  locations  (correlated  and  uncorrelated  spot  reports) 

-  geo-referenced  battlefield  objects  (e.g.,  minefields,  obstacles,  supply  points) 

-  battlefield  graphics  (overlays) 

2.  command  and  control  via  digital  messaging  between  platforms/units  and  linked  to 

higher  echelon  systems  for  handling  intelligence,  logistics,  maneuver  control,  free  text, 
and  other  command-and-control  functions.  Examples  include 

-  field  orders 

-  spot  reports 

-  status  reporting 

-  audio  and  visual  message  alerts  (Nuclear,  Chemical,  Biological  [NBC]]  alerts  and 
other  high-priority  messages) 

Simply  put,  FBCB2  provides  soldiers  with  answers  to  these  basic  questions: 

•  Where  am  I? 

•  Where  are  my  buddies? 

•  Where  is  the  enemy? 

•  What  is  the  environment? 

With  a  clear  picture  of  the  battlefield,  commanders  can  make  decisions  faster  and  communi¬ 
cate  them  faster  than  the  enemy  can  react. 

FBCB2  began  in  1994  as  a  prototype  demonstration  system.  The  Army  has  since  adopted 
FBCB2  for  widespread  use,  including  fielding  the  system  across  a  vast  number  of  Army 
units.  The  program  office  has  proposed  cooperation  with  the  U.S.  Marine  Corps  (USMC)  to 
adopt  FBCB2  as  its  standard  BFT  and  messaging  system.  FBCB2  must  also  interface  to  a 
variety  of  Army,  other  military,  and  coalition  systems.  The  system  matured  through  a  series 
of  tests,  including  the  Task  Force  XXI  Advance  Warfighting  Experiment  (AWE)  at  Fort  Irwin 
and  Limited  User  Tests.  The  Army  initially  fielded  FBCB2  with  the  4th  Infantry  Division 
(Mechanized) — the  Army’s  “First  Digitized  Division” — in  September  2000.  The  Balkan  Dig¬ 
itization  Initiative  proved  the  ability  of  FBCB2  to  support  BFT,  and  the  system  was  widely 
deployed  in  Afghanistan  as  part  of  Operation  Enduring  Freedom  (OEF)  and  in  Iraq  as  part  of 
Operation  Iraqi  Freedom  (OIF).  FBCB2  is  currently  in  use  by  forces  in  the  Balkans,  Afghani¬ 
stan,  and  Iraq.  In  support  of  OIF  alone,  the  Army  has  expedited  delivery  of  more  than  8,800 
systems  on  three  continents,  deployed  with  two  services. 

FBCB2  is  the  Army’s  most  successful  entree  into  battlefield  digitization.  The  program  has 
received  several  national  awards  including 

•  2002:  Top  Five  Quality  Software  Project  (from  the  Software  Technology  Support  Center, 
Hill  Air  Force  Base) 

•  2003:  Network-Centric  Warfare  Most  Innovative  U.S.  Government  Program  (from  the 
Institute  for  Defense  and  Government  Advancement) 
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•  2004:  Monticello  Award  as  “the  information  system  having  the  most  direct  and  meaning¬ 
ful  impact  on  human  lives”  (from  Federal  Computer  Week ) 

As  FBCB2  enjoyed  widespread  acceptance  and  accolades,  the  program  started  to  become  a 
“victim  of  its  own  success.”  With  the  release  of  each  new  system,  the  developers  incorpo¬ 
rated  more  capability.  Although  each  of  those  systems  is  called  FBCB2,  they  were  all  derived 
from  the  initial  operational  version  and  exist  in  slightly  different  configurations.  Each  con¬ 
figuration  is  a  monolithic  system,  loaded  on  individual  platforms,  with  parameterization  that 
determines  capabilities  and  interfaces  for  an  individual  platform.  In  reality,  a  number  of  very 
similar  systems  are  maintained  and  released  as  separate  builds.  Weaknesses  in  this  approach 
and  the  existing  FBCB2  software  architecture  became  apparent.  These  weaknesses  limited 
the  ability  of  developers  to  continue  evolving  FBCB2  both  technically  and  affordably.  Main¬ 
tenance  in  the  field  required  a  dedicated  support  staff,  and  many  functions  could  not  be  used 
because  of  a  lack  of  communications  bandwidth  or  other  limitations.  The  PO  succeeded  in 
maintaining  the  funding  stream  but  could  not  delay  fielding  systems  that  addressed  some  of 
these  deficiencies. 

In  2001,  under  the  direction  of  General  Paul  J.  Kern,  a  study  team  from  the  SEI  began  a  year¬ 
long  investigation  to  assess  the  long-term  sustainability  of  FBCB2  in  light  of  new  emerging 
threats  and  missions.  The  SEI  study  team  concluded  that  FBCB2  software  was  not  on  the  ap¬ 
propriate  architectural  path  for  current  operational  use  or  for  longer  term  use  by  the  Objective 
Force.  The  study  team  recommended  course  corrections  to  address  these  deficiencies.  One  of 
the  recommendations  was  to  rearchitect  the  system  to  support  a  software  product  line  ap¬ 
proach. 

The  NG-PO-SEI  team  began  a  series  of  activities  to  address  the  recommendations,  which 
included  a  redesigned  software  architecture,  known  as  the  Objective  Architecture.  It  included 

•  isolation  of  application  software  from  specific  hardware 

•  development  of  a  uniform,  scalable  interprocess  communication  mechanism  known  as 
the  Node  Data  Broker 

•  design  and  implementation  of  support  for  backward  compatibility 

•  isolation  of  the  applications  from  the  operating  system  through  a  facade 

•  isolation  of  the  software  from  changes  in  message  formats  through  message  agents 

•  use  of  a  display/map  server  to  allow  non-FBCB2  applications  to  display  images  on  an 
FBCB2  map 

Peter  Blankenship  reported  that  initial  results  have  been  generally  positive.  FBCB2  software 
can  be  moved  more  readily  to  a  wide  range  of  platforms.  Moving  core  capabilities,  such  as 
communications  processing,  has  been  relatively  straightforward.  The  Node  Data  Broker  con¬ 
cept  has  facilitated  creation  of  different  configurations  without  undue  burden.  The  use  of 
message  agents  provides  better  isolation  from  changes  over  which  the  FBCB2  program  has 
no  control. 
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Blankenship  also  reported  a  number  of  technical  and  organizational  challenges.  Their  unify¬ 
ing  theme  is  how  to  maintain  a  balance  between  the  cost-  and  schedule-driven  nature  of  the 
program  with  a  focus  on  individual  systems  and  maintenance  of  the  “pure”  approach  to  im¬ 
plementing  a  system  based  on  the  Objective  Architecture.  The  program  must  be  vigilant  in 
ensuring  that  it  does  not  compromise  the  product  line  approach  if  it  takes  shortcuts  to  gain  a 
specific  product  function.  Also,  the  effective  reuse  of  existing  software  assets  requires  con¬ 
siderable  effort.  The  pros  and  cons  of  the  decision  to  mine  a  particular  legacy  asset  must  be 
considered  carefully. 

In  summary,  the  FBCB2  program  is  still  transitioning  to  a  product  line  approach.  From  a 
technical  standpoint,  the  Objective  Architecture  appears  to  provide  a  viable  means  for  achiev¬ 
ing  the  desired  flexibility,  reliability,  and  stability  for  a  family  of  products.  From  an  organiza¬ 
tional  standpoint,  project  personnel  are  more  universally  informed  and  project  practices  are 
stabilizing  around  the  product  line  approach.  The  FBCB2  product  line  offers  substantial  im¬ 
provement  and  growth  opportunities  for  the  program  and  the  Army. 

2.3  Austin  Info  Systems  and  Software  Product 
Lines — Tom  Baker 

Tom  Baker  of  Austin  Info  Systems  (AIS),  Inc.,  presented  an  overview  of  the  AIS  strategy  for 
software  product  lines.  AIS  is  a  small  (100-plus  people)  company  that  provides  analysis,  de¬ 
sign,  development,  and  support  of  complex  information  and  battle  management  systems  [AIS 
05].  The  software  in  such  systems  spans  command,  control,  and  communications  (C3),  intel¬ 
ligence  data  fusion  and  tracking,  fire  control  and  targeting,  and  digital  mapping  and  display. 
The  company  was  driven  to  adopt  a  product  line  approach  for  much  the  same  reason  as  Cel- 
siusTech  Systems  [Bass  03]:  it  would  go  out  of  business  if  it  kept  doing  business  the  old  way. 

AIS  is  adopting  software  product  lines  to  exploit  the  intelligence  business  segment.  The 
company  intends  to  leverage  its  core  capabilities  in  support  of  DoD,  national,  and  interna¬ 
tional  intelligence  programs.  The  basis  for  the  AIS  product  line  is  a  service-oriented  architec¬ 
ture  for  automated  intelligence  analysis  known  as  the  Joint  Intelligence  Toolkit.  The  product 
line  will  provide  increasing  levels  of  capability  to  programs  such  as  DCGS  (Distributed 
Common  Ground  Systems)  and  Future  Combat  Systems  (FCS).  In  FCS,  for  example,  the 
product  line  will  provide  support  for  situation  understanding,  intelligence  data  fusion,  and 
sensor  planning.  The  software  runs  on  Windows  platforms  (with  support  for  UNIX/Linux  for 
targets  such  as  FCS).  Currently  there  are  about  1.5  million  lines  of  code  in  the  unclassified 
code  base  and  about  0.5  million  in  the  classified  code  base. 

The  Joint  Intelligence  Toolkit  has  a  layered  architecture  that  includes  an  application  services 
layer  with  command,  analysis,  and  intelligence  support.  These  services  are  engineered  to  be 
compatible  with  other  DoD  service-oriented  architectures  such  as  the  System  of  Systems 
Common  Operating  Environment  (SOSCOE).  In  fact,  the  application  services  are  a  product 
line  within  the  overall  product  line. 
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AIS  envisions  a  four-step  transition  path  to  software  product  lines: 

1 .  Refactor  existing  software  modules  into  subsystems  and  layers  that  are  service-based 
architecture  (SBA)  compatible.  (This  was  the  focus  of  activities  in  2004.) 

2.  Structure  individual  subsystems  for  participation  in  a  service-based  operating  environ¬ 
ment.  (This  is  the  2005  focus.) 

3.  Extend  individual  subsystem  interfaces  for  compliance  with  targeted  SBA  instances. 

(The  first  of  these  is  SOSCOE;  the  second  is  the  DCGS  integration  backbone.) 

4.  Create  a  production  plan  for  targeted  environments.  (The  first  system  delivery  is  in 
2004,  with  six  more  planned  for  2005.) 

The  goal  is  to  provide  early  fielding  of  capability  for  FCS  and  DCGS.  AIS  has  restructured 
the  company  to  support  these  and  other  key  programs.  AIS  has  also  been  able  to  get  custom¬ 
ers  to  provide  some  of  the  first-year  seed  money  for  the  product  line  effort. 

2.4  The  Common  Avionics  Architecture  System 
(CAAS) — Stephanie  Burns,  Rockwell  Collins 

Rockwell  Collins  is  a  recognized  leader  in  the  development  and  fielding  of  open  systems  so¬ 
lutions,  data  links  and  self-organizing  network  communications,  advanced  display  solutions, 
and  precision  geo-location  and  navigation.  These  key  elements  are  integral  to  enabling  the 
military’s  transformational  objectives.  Rockwell  Collins  plays  a  key  role  in  developing  new 
technology  solutions  such  as  the  Common  Avionics  Architecture  System  (CAAS)  [Rockwell 
04], 

The  CAAS  software  architecture  is  being  used  to  support  the  creation  of  a  software  product 
line  of  cockpit  avionics  software  for  special  operations  helicopters:  the  MH-47G  Chinook, 
the  MH-60M  Black  Hawk,  and  the  MH/AH-6M  Little  Bird.  The  software  product  line  will 
enable  the  introduction  of  unparalleled  capabilities  for  situational  awareness  and  connectivity 
into  these  cockpits  and  will  help  the  special  operations  aircrews  better  manage  cockpit  work¬ 
load  in  a  uniform  manner.  Moreover,  it  will  facilitate  the  integration  of  these  new  technolo¬ 
gies  with  existing  systems,  allow  for  easier  upgrades  in  the  future,  and  simplify  integration  of 
equipment  and  software  from  third-party  vendors.  A  Rockwell  Collins  Research  and  Devel¬ 
opment  (R&D)  project  derived  the  software  architecture  from  the  Rockwell  Collins  Flight2 
avionics  architecture  used  in  military  and  commercial  aircraft  such  as  the  KC-135  and  Boeing 
767. 

The  vision  for  CAAS  was  to  create  a  scalable  system  that  would  address  obsolescence  and 
modernization  issues  in  multiple  helicopter  cockpits,  and  would  reduce  total  cost  of  owner¬ 
ship  by  using  a  single,  open,  common  avionics  architecture  system  for  all  platforms.  The 
drivers  for  adopting  the  CAAS  approach  were  an  open  system  architecture,  variability  isola¬ 
tion,  connectivity,  supportability,  and  modularity,  all  of  which  are  essential  to  providing  eco¬ 
nomical  total  cost  of  ownership. 
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Rockwell  Collins  is  the  software  integrator  for  CAAS  and  the  provider  of  multifunction  dis¬ 
plays,  control  display  units,  and  general-purpose  processing  units  shared  by  all  three  helicop¬ 
ters.  Multiple  isolated  applications  can  run  on  a  single  processor,  and  the  open  system  archi¬ 
tecture  simplifies  connectivity  and  support.  The  scalable  CAAS  uses  one  Power  PC  750 
processor  in  each  Control  Display  Unit  (CDU)  and  two  Power  PC  750  processors  in  each 
Multifunction  Display  (MFD).  The  open  system  architecture  is  meant  to  simplify  connec¬ 
tivity  and  support,  including  the  ability  to  swap  line-replaceable  units  between  platforms  in 
the  field.  The  common  avionics  hardware  and  software  in  all  three  aircraft  will  reduce  the 
logistics  demands  on  aviation  units  and  simplify  training.  Additionally,  the  commonality  of 
software  and  hardware  components  is  expected  to  provide  the  Special  Operations  Forces  a 
lower  total  life-cycle  cost  and  lower  costs  for  technology  insertion  and  supportability. 

Some  of  the  strengths  of  the  software  product  line  approach  are  that  it  supports  insertion  of 
new  technology,  enables  multifunction  displays  and  other  avionic  equipment  units  to  be 
swapped  out  from  one  helicopter  avionics  system  to  another  with  automatic  reconfiguration, 
and  accommodates  integration  of  subsystems  by  third-party  developers  through  well-defined 
application  program  interfaces  (APIs).  The  system  complies  with  the  Joint  Technical  Archi¬ 
tecture-Army  (JTA-A)  requirements,  using  industry-standard,  system-level  interfaces:  MIL- 
STD-1553  and  AREMC  429  for  legacy  equipment,  SMPTE  292  HDTV  video  standard  for 
system  video,  and  IEEE  802.3  for  Ethernet  connectivity. 

CAAS  embodies  an  open  system  architecture  designed  using  a  layered  approach  with  widely 
accepted  interfaces,  separating  hardware  from  software,  and  software  services  from  system 
functional  logic.  The  system  functionality  itself  is  partitioned  into  separate  software  compo¬ 
nents  and  isolated  through  published  and  controlled  interface  definitions.  This  approach  al¬ 
lows  hardware  and  software  components  to  be  replaced  or  upgraded  independently  and  helps 
to  lessen  integration  issues.  The  approach  also  allows  problem  fixes  to  be  migrated  to  all  sys¬ 
tems.  The  layered  architecture  facilitates  product  development  by  application  teams  having 
specific  domain  expertise. 

The  product  line  scope,  while  bounded  by  the  aviation  platforms  it  will  support,  is  now 
changing.  More  variability  is  being  introduced  because  of 

•  plans  to  add  more  avionics  platforms  that  will  draw  from  the  same  logistics  pool  of 
hardware  and  software  components 

•  an  introduction  of  new  system  features  traditionally  used  by  service-oriented  architec¬ 
tures 

•  the  Army’s  desire  to  reuse  software  components  across  dissimilar  platforms.  One  driver 
for  this  is  that  the  conventional  Army  expects  to  upgrade  its  CH-47D  helicopters  to  CH- 
47Fs,  and  some  of  them  will  be  converted  into  MH-47Gs  for  special  operations. 

The  architecture’s  impact  on  total  life-cycle  cost  is  that  it  will  reduce  non-recurring  engineer¬ 
ing  costs  to  upgrade  or  add  new  functionality,  and  it  will  allow  use  of  all  available  processing 
reserves  when  the  system  is  upgraded,  without  requiring  drastic  rerouting  of  system  data.  A 
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Software  Application  Developer’s  Toolkit  is  available  to  third  parties  so  that  they  can  migrate 
and  integrate  their  software  applications  on  CAAS  processing  platforms  or  incorporate  third- 
party  equipment  using  dissimilar  processing  platforms. 

2.5  RangeWare — Ed  Dunn,  NUWC 

Ed  Dunn  of  the  Naval  Undersea  Warfare  Center  (NUWC)  presented  an  update  of  product  line 
activities  within  his  organization.  As  a  development  lab  component  of  the  Naval  Sea  System 
Command  (NAVSEA)-Division  Newport,  NUWC  is  the  Navy’s  full-spectrum  research,  de¬ 
velopment,  test  and  evaluation,  engineering,  and  fleet  support  center  for  submarines,  autono¬ 
mous  underwater  systems,  and  offensive  and  defensive  weapons  systems  associated  with  un¬ 
dersea  warfare  [NUWC  04], 

Product  lines  are  a  reality  within  NUWC.  Currently,  the  product  line  includes  10  projects. 
There  has  been  local  acceptance  within  the  test  ranges  currently  supported  by  Dunn’s  branch, 
but  the  product  line  approach  is  not  yet  institutionalized  across  NUWC.  Organizationally, 
Dunn’s  branch  does  not  have  a  complete  infrastructure  in  place  to  support  widespread  sharing 
of  processes  or  architectures  across  NUWC. 

The  software  branch  that  Dunn  represents  deals  with  variations  in  testing  systems  that  cover 
live  test  ranges,  augmented  with  simulations.  In  other  words,  the  organization  builds  test 
software  to  manage,  execute,  and  report  test  exercises  that  are  conducted  with  live,  opera¬ 
tional  assets  (e.g.,  submarines,  torpedoes,  and  sonobuoys).  But  the  test  software  must  also 
deal  with  test  exercises  where  simulation  software  is  substituted  for  one  or  more  of  these  as¬ 
sets.  A  current  project  is  working  on  a  widely  expanded  architecture,  built  on  the  RangeWare 
asset  base  described  in  previously  referenced  DoD  workshop  reports  and  the  work  of  Cohen, 
Dunn,  and  Soule  [Cohen  02]. 

Together  with  the  SEI,  NUWC  has  produced  a  series  of  case  studies  and  a  product  line  busi¬ 
ness  case.  As  reported  at  the  Sixth  DoD  Workshop  [Bergey  04a],  NUWC  has  launched  a 
measurement  program  to  address  the  need  for  better  measurement  standards  to  validate  busi¬ 
ness  case  results.  The  NUWC  staff  developed  measurement  goals,  identified  and  collected 
data  to  validate  that  goals  are  being  met,  and  produced  a  plan  to  use  results  to  show  manage¬ 
ment  the  effectiveness  of  the  product  line  approach. 

The  hope  within  NUWC  is  that  documented  product  line  results  will  overcome  the  difficulty 
of  justifying  strategic  funding  to  support  product  line  adoption.  Another  goal  is  to  know  when 
the  product  line  approach  is  not  appropriate  for  a  new  area  or  when  a  specific  product  falls 
outside  of  the  scope  of  an  existing  product  line.  For  example,  while  an  experimental  system 
may  be  built  quite  easily  using  product  line  assets,  turning  that  experimental  system  into  a 
fielded  product  may  be  outside  the  product  line  scope  or  exceed  product  line  capabilities. 
Measuring  the  effectiveness  of  the  product  line  for  a  specific  product  could  be  a  useful  risk 
management  tool. 
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2.6  Argon  Engineering  Associates  and  Software 
Product  Lines — Dave  Drum,  Argon 

Argon  Engineering  Associates  is  a  rapidly  growing  systems  engineering  and  development 
company  providing  full-service  information  solutions  to  a  wide  range  of  customers.  The  Ar¬ 
gon  business  vision  is  to  grow  by  providing  creative  state-of-the-art  technology  solutions  to 
difficult  system  problems.  Argon’s  current  challenges  include  the  design  and  development  of 
communication  systems  that  search,  identify,  and  capture  signals.  This  work  includes  sensor 
development,  data  collection  and  decision  support,  and  analysis  and  design  of  information 
retrieval  and  visualization  techniques  [Argon  04]. 

Argon  uses  a  product  line  approach  to  develop  and  deploy  many  of  its  systems.  Among  the 
benefits  it  has  seen  from  the  product  line  approach  are 

•  shorter  development  and  delivery  schedules 

•  lower  development  and  upgrade  costs 

•  lower  total  ownership  costs 

•  support  for  an  incremental  development  model 

•  shared  development  and  technology  costs 

•  production  of  best-in-class  commercial  off-the-shelf  (COTS)  and  government  off-the- 
shelf  (GOTS)  products 

•  continuous  technology  insertion 

Argon’s  product  line,  which  is  called  Lighthouse,  is  based  on  a  true  product  line  approach 
that  enables  the  company  to  avoid  developing  unique  point  solutions  by  fielding  a  family  of 
related  systems.  Use  of  a  common  architecture  and  common  asset  base  enables  Argon  to  meet 
its  customer’s  cryptologic  needs  on  a  variety  of  platforms  using  current  technology.  These 
platforms  include 

•  manned  and  unmanned  airborne 

•  submarine  and  unmanned  undersea  vehicle  (UUV) 

•  ship 

•  land  and  land  mobile 

In  developing  its  product  line,  Argon  had  to  define  common  capabilities  from  all  its  various 
customer  requirements  to  achieve  broadly  capable  software  that  could  execute  on  general- 
purpose  hardware.  In  effect,  Argon  has  pulled  its  customers  together  (as  a  user  group)  based 
on  needed  capabilities  because  there  is  no  desire  to  merge  deliveries  among  programs  and  no 
means  to  make  it  happen.  Customers  typically  have  little  motivation  to  align  their  schedules 
to  benefit  a  product  line  approach,  as  they  are  only  interested  in  their  particular  communica¬ 
tion  and  intelligence  (COMINT)  systems.  Modularity  was  stressed  to  permit  adaptation  of 
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capability  over  time.  Lighthouse  relies  heavily  on  COTS  hardware  and  software;  in  some 
cases,  the  use  of  COTS/GOTS  hardware  and  software  is  required. 

Argon’s  production  model  is  driven  by  a  system  requirements  document  and  includes  parallel 
paths  for  individual  product  developments  through  a  common  asset  base  to  facilitate  asset 
integration  and  synchronized  build  processes.  Production  involves  a  matrix  of  assets,  asset 
groups,  producers,  enhancers  and  users.  The  assets  themselves  are  developed,  enhanced,  or 
used  by  three  product  line  groups:  (1)  signal  processing,  (2)  real-time  infrastructure,  and  (3) 
operability.  While  programs  are  the  primary  contributors  to  the  development  and  enhance¬ 
ment  of  the  asset  base,  independent  research  and  development  projects  also  contribute  to  the 
asset  base.  New  missions  are  met  primarily  with  new  software  that  is  then  mined  for  assets 
that  can  be  folded  back  into  the  product  line. 

Argon  is  currently  delivering  systems  to  the  U.S,  United  Kingdom,  and  Australian  military 
services  to  satisfy  their  cryptologic  needs.  The  time  to  field  a  new  system  has  typically  been 
reduced  from  three  or  four  years  to  one  year. 

Argon  has  addressed  these  product  line  challenges  in  the  DoD  environment : 

•  imposed  size,  weight,  and  cost  constraints  from  hardware 

•  accommodating  different  funding  and  development  cycles  across  customers  and  releases 

•  having  a  model  for  cost  estimation  and  funding  that  supports  various  contract  types  and 
development  and  maintenance 

•  managing  technology  evolution  for  long  duration  programs  (20-plus  years)  for  major  ar¬ 
chitecture  changes,  technology  refresh,  and  technology  insertion 

2.7  Army  Training  Support  Center  (ATSC) — Frank 
Polster 

Bringing  the  group  up  to  date  on  last  year’s  workshop  presentation,  Frank  Polster  reported 
that  further  significant  organizational  improvements  were  made  following  the  use  of  the  SEI 
Product  Line  Technical  ProbeSM  (PLTPSM),  the  subsequent  planning  sessions  to  address  the 
PLTP  findings,  and  the  use  of  the  SEI  Architecture  Tradeoff  Analysis  Method®  (ATAM®). 
The  ATSC  staff  members  see  product  line  technology  as  the  way  to  embed  training  systems 
in  Army  combat  systems.  They  are  involved  in  the  Army’s  FCS  planning  and  see  this  as  the 
likely  mechanism  to  carry  forward  many  of  their  product  line  ideas. 


SM  Product  Line  Technical  Probe  and  PLTP  are  service  marks  of  Carnegie  Mellon  University. 

®  Architecture  Tradeoff  Analysis  Method  and  ATAM  are  registered  in  the  U.S.  Patent  and  Trade¬ 
mark  Office  by  Carnegie  Mellon  University. 
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2.8  Army  Program  Executive  Office  (PEO) 

Aviation — James  Baxter 

The  Program  Executive  Office  (PEO)  Aviation  is  the  Army  manager  for  combat,  cargo,  and 
utility  helicopters.  It  is  also  responsible  for  unmanned  aerial  vehicles  (UAVs)  and  other  Army 
aviation  programs.  The  program  executive  officer  reports  directly  to  the  Army  acquisition 
executive.  “PEO  Aviation  is  the  responsible  management  official  who  provides  overall  direc¬ 
tion  and  guidance  for  the  development,  acquisition,  testing,  systems  integration,  product  im¬ 
provement  and  fielding  of  assigned  programs”  [PEO  Aviation  04]. 

PEO  Aviation  sees  three  primary  goals  in  its  software  improvement  programs: 

1.  Achieve  better  integration  within  platform  architectures,  eliminating  major  rewrites  for 
each  upgrade. 

2.  Identify  and  exploit  commonality. 

3.  Support  integration  and  interoperability  across  Army  aviation  platforms. 

The  PEO  has  identified  several  approaches  to  address  these  goals  through  adoption  of  a 
product  line  approach: 

•  Eliminate  the  need  for  multiple  versions  of  software.  Achievement  of  this  goal  would 
eliminate  the  current  platform-centric  development,  which  looks  at  each  aircraft  as  a 
separate  build.  Instead,  a  product  line  approach  would  involve  moving  to  an  architecture¬ 
centric  approach  that  supports  software  reuse  across  platforms. 

•  Eliminate  closed/proprietary  architectures  via  migration  to  mission-centric  approaches. 
Currently,  each  manufacturer/developer  has  its  own  architecture.  All  upgrades  and  modi¬ 
fications  are  tied  to  that  single  organization.  Two  plans  are  underway  that  would  create 
non-proprietary  solutions: 

1.  Common  Aviation  Architecture  System  (CAAS)  for  special  operations,  cargo,  and 
utility 

2.  Manned/Unmanned  Common  Architecture  Program  (MCAP)  for  Apache  helicopters 

A  further  step  would  be  to  merge  these  two  architecture  solutions. 

Army  Aviation  is  also  participating  in  the  new  Army  FCS  program.  This  program  will  pro¬ 
vide  new  UAVs,  but  more  importantly  will  introduce  the  concept  of  network-centric  warfare 
to  support  interoperability.  A  System  of  Systems  Common  Operating  Environment  (SOS- 
COE)  is  envisioned  for  FCS  to  support  all  future  platforms.  From  a  product  line  perspective, 
there  are  questions  about  the  suitability  and  variability  of  SOSCOE  to  support  real-time  avia¬ 
tion  needs,  as  opposed  to  more  conventional  command  and  control. 
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2.9  The  Common  Gunnery  Architecture— Dean 

Runzel,  Army  PEO  for  Simulation,  Training,  and 
Instrumentation 

Dean  Runzel  of  the  U.S.  Army  Program  Executive  Office  for  Simulation,  Training,  and  In¬ 
strumentation  (PEO  STRI)  presented  an  overview  of  an  effort  to  standardize  gunnery  training 
systems.  The  Army  currently  has  eight  different  trainers  built  by  three  different  contractors 
for  the  Abrams,  Bradley,  and  Stryker  platforms.  There  is  no  interoperability  among  the  three 
different  contractor  baselines;  even  trainee  records  cannot  be  moved  across  the  systems,  be¬ 
cause  the  databases  are  different.  The  envisioned  solution  to  the  interoperability  problem — 
and  to  the  related  stovepiped  life-cycle  support  problems — is  the  common  gunnery  architec¬ 
ture  (CGA). 

The  CGA  is  an  extension  of  the  One  Semi-Automated  Forces  (OneSAF)  Objective  System 
(OOS)  product  line  architecture  framework.  The  CGA  provides  a  common  baseline  for  all 
gunnery  trainers;  it  incorporates  requirements  from  existing  systems  in  a  core  set  of  require¬ 
ments.  The  common  baseline  will  include  universal  student  records,  universal  terrain  data¬ 
bases,  universal  dynamic  terrain  effects,  and  universal  entity  behaviors.  Among  other  things, 
the  CGA  is  intended  to  permit  training  in  contemporary  operating  environments  and  urban 
environments,  minimize  the  cost  of  concurrency  and  obsolescence,  and  bridge  the  gap  with 
the  FCS.  (Coordination  between  PEO  STRI  and  FCS  is  needed  for  the  training  portion  of 
FCS  so  that  FCS  does  not  develop  its  own  solution  outside  of  the  CGA.)  The  CGA  will  also 
leverage  the  current  investment  in  the  Stryker  Mobile  Gun  System  (MGS)  training  system. 

The  government  owns  the  CGA.  Contracts  will  be  awarded  to  develop  specific  components 
(e.g.,  a  crew  station  interface),  while  other  components  will  be  provided  to  contractors  as 
govemment-fumished  information  (e.g.,  the  after-action  review  portion  and  the  training  man¬ 
agement  system).  Because  of  the  commonality,  there  is  a  potential  to  extend  the  CGA  to 
every  training  device  produced  by  PEO  STRI. 

The  anticipated  benefits  of  the  CGA  include 

•  cost  savings  in  software  maintenance  and  flexibility  in  responding  to  changes  in  tactics, 
techniques,  and  procedures 

•  cost  avoidance  because  of  no  redundant  development 

•  better  products  with  added  functionality 

A  10-year  cost-benefit  analysis  of  the  CGA  was  conducted,  with  the  following  assumptions: 

•  All  eight  training  devices  migrate  to  the  CGA  in  fiscal  year  2007-2008. 

•  Migration  occurs  in  conjunction  with  each  system’s  scheduled  technical  refresh  efforts. 

•  A  single  integrated  development  environment  and  support  organization  is  established. 

The  analysis  showed  a  potential  $66  million  in  cost  avoidance. 
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3  Summary 


The  SEI’s  Seventh  DoD  Product  Line  Practice  Workshop  explored  the  product  line  practices 
of  organizations  in  the  DoD  community  in  light  of  best  commercial  practices  and  government 
experience.  This  workshop  demonstrated  a  continuance  of  the  trend  revealed  during  the  sixth 
workshop:  namely,  software  product  line  practice  is  becoming  a  reality  in  the  DoD.  Almost 
all  the  presentations  were  based  on  experience  rather  than  plans  or  speculation.  The  discus¬ 
sions  validated  the  pivotal  pieces  of  the  framework  and  provided  valuable  feedback  on  the 
companion.  Challenges  and  experience-based  solutions  were  discussed. 

As  in  previous  workshops,  the  empirical  and  anecdotal  evidence  that  the  workshop  partici¬ 
pants  brought  to  the  discussion  significantly  enhanced  mutual  understanding  of  the  practices 
and  issues  as  they  apply  to  the  DoD.  Traditional  DoD  acquisition  strategies  are  not  naturally 
conducive  to  software  product  lines.  However,  it  is  clear  that  product  line  practice  is  possible 
within  the  DoD,  and  more  DoD  organizations  are  taking  a  product  line  approach. 

In  an  effort  to  expand  both  the  information  base  and  the  DoD  community  interested  in  soft¬ 
ware  product  lines,  the  SEI  was  encouraged  by  the  participants  to  continue  to  hold  similar 
workshops. 

As  before,  results  of  this  workshop  will  be  incorporated  into  the  acquisition  companion  to  the 
framework,  which  will  continue  to  be  refined  and  revised  as  the  technology  matures  and  as 
the  SEI  continues  to  receive  feedback  [Bergey  04b].  If  you  have  any  comments  on  this  report 
or  are  using  a  product  line  approach  in  the  development  or  acquisition  of  software-intensive 
systems  for  the  DoD  and  would  like  to  participate  in  a  future  workshop,  please  send  email  to 
Linda  Northrop  at  lmn@sei.cmu.edu. 
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